Some businesses are structured to sell good or services in multiple batches to patrons over a relatively short period of time. For example, a patron of a bar or night club may purchase multiple rounds of drinks of the course of an evening. Typically, the transaction associated with the purchase of each round of drinks will involve the following steps:                (a) the patron queuing up at the bar, waiting to catch the bartender's attention;        (b) placing an order for desired drinks;        (c) receiving the drinks;        (d) checking that drinks presented match what was ordered; and        (e) making payment by cash, credit card or by any other acceptable means.        
The step of making the payment is an essential part of the process. However, it is often a time consuming and generally inconvenient part of this time honoured tradition. This is especially the case where:                (a) the patron stays at the bar for an extended period of time purchasing multiple rounds of drinks;        (b) the bar is busy and there are numerous patrons all jockeying for position to get service; and/or        (c) credit card payments are made for each transaction.        
With regard to the latter point, a great deal of time and inconvenience can be spent processing a credit card payment by both the merchant's employee and the patron.
As a consequence of the above described difficulties, added pressure is placed on the merchant's staff who are attempting to service the patrons. This may lead to job dissatisfaction and higher turnover in staff. It may also lead to patron dissatisfaction and, in the long term, less patrons returning to the bar.
Many systems and processes have been devised to assist merchants to provide patrons with more efficient payment options. For example, rather than paying for each round of drinks individually, some bars will allow patrons to set up an account (hereafter referred to as a “tab”) which will be used to record the details of each one of the patron's orders.
This system relies on the patron making payment at the end of the night before leaving the bar. Typically, before the customer leaves the bar, he or she needs to:                (a) ask the merchant to total up the items on the tab and to produce an invoice;        (b) review the itemised list of goods purchased on the invoice and confirm that it is accurate; and        (c) effect payment by cash, credit card, or any other means which is acceptable to the merchant.        
Using a tab in the above described manner can make the process of purchasing goods more efficient which has benefits for both the patron and the merchant's staff. However, difficulties can arise where:                (a) the patron leaves the bar without first paying the tab; or        (b) the patron discovers that he or she cannot make payment of the tab due to lack of cash, credit or any other suitable means of payment.        
To reduce the likelihood of such difficulties arising, some bars request you to secure the tab by the patron giving the merchant his or her credit card to hold whilst the tab is open. This provides increased security for the merchant. However, often bars do not request preauthorisation of a tab limit on the credit card and, as such, the merchant cannot be certain that:                (a) there is sufficient credit on the card to cover the tab when the patron leaves the bar; and/or        (b) the credit card is not stolen.        
In addition to the above-described difficulties, the practice of keeping credit cards as security for tabs is changing around the world. For example, in some jurisdictions, the laws now require the merchant to take steps to ensure that the cards are securely stored whilst the tab is open. In some cases, there are even requirements to store the cards in the merchant's safe during this period. Plainly, meeting such requirements can be time consuming and can place an extra burden on the merchant and/or his or her staff.
Further difficulties can arise for the patron where, at the end of his or her night, it is generally inconvenient to retrieve the credit card from the bar and close off the tab. This may be due to the queue at the bar being too lengthy which is particularly problematic at the end of a long night out. Alternatively, difficulties can arise where a credit card is accidently left at the bar due to intoxication, fatigue and/or absentmindedness. In this case, the patron needs to return to the bar to close off the tab and retrieve his or her credit card. In the meantime, the patron is relying on the merchant to not use the card in an unauthorised manner and to ensure that the card is securely stored until it is collected.
Although the above mentioned difficulties are described by way of example to a bar, the difficulties are relevant to many other businesses where a patron effects multiple purchases of goods or services over short period of time. For example, ordering food and drinks at a restaurant or a café, or purchasing tickets for rides at a carnival.
Many methods of conducting secure electronic commerce transactions are known in the art. U.S. Pat. No. 7,058,611 describes in some detail a method involving the SET™ protocol which facilitates secure payment card transactions over the Internet. The disclosure of U.S. Pat. No. 7,058,611 in its entirety is hereby incorporated by way of reference.
Using the SET protocol, cryptography is utilized to ensure confidential and secure transmissions of data and digital certificates to create a trust chain throughout the transaction, verifying cardholder and merchant validity. There have been numerous extensions and additions to the SET specification, all of which are presently available on SETCo's website, setco.org. The SET protocol (“SET”) is typically invoked after a consumer has completed the payment and other information on an order form and is ready to return the order form to the merchant.
SET changes the way that participants in a payment system interact. In a face-to-face retail transaction or a mail order transaction, electronic processing begins with the merchant or the acquirer. However, in a SET transaction, the electronic processing begins with the cardholder.
In the electronic commerce environment, consumers and corporate purchasers generally interact with merchants from personal computers. A cardholder (or account holder—a physical card is not necessary) uses a payment account number or card that has been issued by an issuer. SET ensures that the cardholder's interactions with the merchant, and specifically the payment card account information, remains confidential. The typical participants, entities or components (in addition to the account holder) involved in a SET transaction are the issuer, the merchant, the acquirer and payment gateway, each of which can be described as follows:    1. An issuer is a financial institution that establishes an account for a cardholder and most often issues the payment card. The issuer guarantees payment for authorized transactions using the payment card in accordance with payment card brand regulations and local legislation.    2. A merchant offers goods for sale or provides services in exchange for payment. With SET, the merchant can offer its cardholders secure electronic interactions. A merchant that accepts payment cards must have a relationship with an acquirer, which is the financial institution that establishes an account with a merchant and processes payment card authorizations and payments.    3. A payment gateway is a device operated by an acquirer or a designated third party that processes merchant payment messages, including payment instructions from cardholders.
As mentioned above, SET is an Internet transaction protocol which provides security through authentication. It enforces a series of checks and counterchecks between the participants' computers to ensure details are processed correctly, safely and securely. In this way, SET creates a trust framework around the electronic commerce transaction process, ensuring confidentiality, data integrity and authentication of each party.
As described, SET uses encryption technology and digital certificates as the basis for electronic commerce transactions. There are several components required for SET to work:    1. Digital Certificates;    2. Certificate Authorities;    3. Cardholder Wallet and Encryption;    4. Merchant SET Software Requirements; and    5. Payment Gateways.
To become SET-compliant, merchants simply need to integrate a SET software component into their virtual storefront system. This SET software then facilitates the actual authorization and settlement process of the payment transaction. The SET module is software developed from the SET specifications.
The SET Transaction Process
Once a consumer has selected items for purchase from an Internet retailer's website and has been presented with an order form, the SET transaction process begins as follows:    1. The cardholder (or account holder) selects the ‘Payment with SET’ option and then chooses their form of payment e.g. Visa, MasterCard etc.    2. The merchant ‘wakes up’ the cardholder's SET wallet, which sends a message to the merchant indicating which payment card the consumer is using.    3. An exchange takes place between the merchant and cardholder, authenticating each party and encrypting the payment information. This encrypted data is then forwarded to the merchant, which sends it, still encrypted, to the SET payment gateway.    4. The SET payment gateway authenticates all the parties in the transaction and forwards the authorization request into the payment network and processes the transaction with its normal authorization process.    5. If approved, the merchant ships the requested goods or provides the requested service and, in return, receives payment from its financial institution.
More recently, the 3-D Secure protocol has gained prominence as a way of adding a security layer to online e-commerce transactions. Two implementations of 3-D Secure are known as Verified by Visa and MasterCard SecureCode.
Verified by Visa Acquirer and Merchant Implementation Guide (http://usa.visa.com/download/merchants/verified-by-visa-acquirer-merchant-implementation-guide.pdf) describes a 3D secure online program designed to make Internet purchase transactions safer by authenticating a cardholder's identity at the time of purchase, before the merchant submits an authorization request. This document, in its entirety, is hereby incorporated into this specification for all purposes by way of reference.
MasterCard Secure Code (https://www.mastercard.us/content/dam/mccom/en-us/documents/SMI_Manual.pdf) describes another 3D secure online program. This document, in its entirety, is hereby incorporated into this specification for all purposes by way of reference.
U.S. patent application Ser. No. 13/209,312 (Wong) generally discloses a phone-based electronic wallet that provides transactions across multiple channels of commerce. The electronic wallet described therein can be used for point of sale payments, remote mobile payments and/or web based payments. The disclosure of U.S. patent application Ser. No. 13/209,312 in its entirety is hereby incorporated into this specification by way of reference.
FIG. 1 is a flow chart depicting the wallet application being used in an e-commerce transaction (e.g., a phone-initiated transaction) with an online PIN. Paragraph 39 of Wong provides the following summary of with reference to that Figure:                In step 300, the consumer selects the “wallet” icon on the merchant's site. The consumer then selects the wallet application (step 302), which then displays a log in form (step 304). Alternatively, the wallet may be auto-detected. The consumer logs in at step 306, views the listed cards at step 308, and thereafter selects the appropriate payment card and shipping details (step 310). At step 312, the wallet questions whether an online PIN is associated with the card. The existence of the online PIN is confirmed at step 314. In step 316, the wallet requests entry of the online PIN into the phone. The online PIN is entered at step 318. Thereafter, the online PIN is encrypted (step 320), and forwarded to the merchant for authorization (step 322). The transaction is validated at step 324, payment is approved at step 326, resulting in a happy consumer (step 328).        
U.S. patent application Ser. No. 13/835,088 (Nwokolo) generally discloses a system of tokenizing sensitive cardholder payment information for use in cashless transactions. The disclosure of U.S. patent application Ser. No. 13/835,088 in its entirety is hereby incorporated into this specification by way of reference. Tokenization is also described in detail in the document “EMV Payment Tokenisation Specification—Technical Framework” (version 1.0, March 2014) of EMV Co., which is hereby incorporated into this specification for all purposes by reference. The EMV Payment Tokenisation Specification is available at www.emvco.com.
Nwokolo identifies that electronic wallets are becoming a more prevalent counterpart to electronic forms of payment for a wide variety of transactions. Nwokolo puts forward that the system above described in Wong, together with the system being the subject of U.S. patent application Ser. No. 13/746,904 entitled “System and method to enable a network of digital wallets”, includes a federated network of electronic wallets. The purchaser may select this network of wallets which includes partners who are members of the federation, each of whom provide electronic wallet services. One option presented to the purchaser may be the option to use an electronic wallet maintained and provided by the payment processing entity, e.g., MasterCard International Incorporated (assignee of the instant application), which is also operating the network of wallets.
Given the overwhelming volume of transactions consummated per second, and the necessity that transactions be authorized expeditiously in order to be an acceptable form of payment for all parties involved in the transaction, the circumstances naturally lend themselves to automation of the approval process. However, without adequate oversight on an individual or per-transaction basis, and/or without the parties to the transaction being known to others involved, including the intermediary, the opportunity for malicious abuse of the payment system require adequate safeguards.
A problem presented is where the transaction details required to consummate a purchaser's transaction may be used thereafter for malicious purposes, for example if the security of such data is compromised by a third party, or by another bad actor with access to cardholder data used during the transaction.
As a solution to this problem, Nwokolo provides the system shown in FIG. 2 which generally performs the steps of:    (a) receiving a request to process a cashless transaction between a merchant and a purchaser using first payment data stored with an electronic wallet provider on behalf of the purchaser.    (b) receiving first payment data from the electronic wallet provider;    (c) tokenizing the first payment data into a payment token; and    (d) providing the payment token to the merchant for use in completing the cashless transaction.
The merchant issues a request to process payment for the cashless transaction using the payment token. The payment token is detokenized into second payment data, with correspondence between the first and second payment data being indicative of payment token authenticity. Payment for the cashless transaction is processed using the second payment data, and the merchant is provided with a response indicating either the success or failure of the payment processing.
It is generally desirable to improve patron experiences with making payments for goods and services. It is also generally desirable to improve merchant and/or merchant employee experiences with making payments.
It is generally desirable to overcome or ameliorate one or more of the above described difficulties, or to at least provide a useful alternative.